home *** CD-ROM | disk | FTP | other *** search
- % appendix B
-
- \appendix{B}{A Short Exchange}
-
- The simple nature of the interchange between the user and \MH/
- in Appendix~A completely hides any interactions between the \TMA/
- and the \KDS/.
- Let us briefly examine an exchange that might occur
- after the destination \TMA/ receives the message shown in Figure~\before.
-
- To begin,
- the \TMA/ must ascertain what it knows about the sender of the message,
- which claims to have a \KDS/ ID of~17.
- That is,
- the \TMA/ must first consider what key relationships it has with the sender.
- For the sake of argument,
- suppose that this purported subscriber is unknown to the \TMA/.
- In this case,
- the first step it must undertake is to ascertain the validity of this
- subscriber.
-
- \tagdiagram{B1-1}{Ascertaining the Sender}{rui}
- As shown in Figure~\rui\ on lines~1--7,
- the \TMA/ does this by establishing a connection to the \KDS/ and issuing an
- {\it request identified user} (RUI) MCL.%
- \nfootnote{In point of fact,
- the {\it very} first thing that the \TMA/ does after connecting to the \KDS/
- is verify that the key relationships between the \KDS/ and the \TMA/ are
- valid (have not expired).
- If the key relationship between the two has expired,
- the \TMA/ issues a {\it request service initialization} RSI MCL to
- establish a new key relationship.
- This relationship contains a {\it key-encrypting key} (KK)
- and an {\it authentication key} (KA).
- Once a valid key relationship exists between the \KDS/ and the \TMA/,
- transactions concerning other key relationships may take place.}
- If the response by the \KDS/ is positive,
- the \TMA/ will use the information returned when generating the
- \eg{X-KDS-ID:} field for authentication.
- The response \CSM/ returned by the \KDS/ includes
- an {\it authentication checksum} (the MAC field on line~15)
- and a {\it transaction count} (the CTA field on line~12)
- to prevent spoofing by a process pretending to be the \KDS/.
- The \TMA/ then acknowledges that the response from the server was acceptable
- on lines~18--24.
-
- The next step is to ascertain the actual key relationship used to encrypt the
- structure $m$, which appears after the identifying string.
- The \TMA/ consults the IDK field in $m$,
- and if this relationship is unknown to it,
- then the \KDS/ is asked to disclose the key relationship.
-
- \tagdiagram{B1-2}{Ascertaining the Key Relationship}{rsi}
- As shown in Figure~\rsi\ on lines~1--9,
- This is done by issuing a {\it request service initialization} (RSI) MCL
- and specifying the particular key relationship of interest.
- The \KDS/ consults its database,
- and if the exact key relationship between the two indicated \TMA/s can be
- ascertained,
- it returns this information.
- The key relationship
- is encrypted using the key relationship between the \KDS/ and the \TMA/,
- and the usual count and authentication fields are included.
-
- Once the \TMA/ knows the key relationship used to encrypt the structure $m$,
- it can decider the structure and ascertain the KD/IV/KA triple used to
- encrypt the body of the message.
-
- % <--- (
- % <--- MCL/RSI
- % <--- ORG/3
- % <--- KDC/TTI
- % <--- SVR/*KK.KD
- % <--- EDC/dabfdb4c
- % <--- )
- % ---> (
- % ---> MCL/RTR
- % ---> ORG/3
- % ---> *KK/926b876cafce46cd365382c36a40fa80
- % ---> CTA/1
- % ---> KD/1eea5394e6ad1b75
- % ---> KD/6c95c8d2caa75807
- % ---> EDK/850618075827
- % ---> KDC/TTI
- % ---> MAC/501f71b6
- % ---> EDC/5bd7b2d0
- % ---> )
- % <--- (
- % <--- MCL/ACK
- % <--- ORG/3
- % <--- KDC/TTI
- % <--- EDC/db46ce7e
- % <--- )
-